home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / graphics / povibm20.zip / Q&A.DOC < prev    next >
Text File  |  1993-10-01  |  13KB  |  211 lines
  1.  
  2.  
  3. POV-Ray Questions & Answers.                                 B.Pulver 5/9/93 
  4. -----------------------------------------------------------------------------
  5.  
  6. This document addresses some of the most commonly asked questions about
  7. POV-Ray and the way it works. It applies only to compiles of POV-Ray done
  8. with Intels "Code Builder Kit" (ICB) 32bit extended DOS compiler. It also
  9. includes some hints on maximizing rendering speed toward the end of the 
  10. file.
  11.  
  12.  
  13. This document gives a (real) quick overview of the POV-Ray operating 
  14. environment. It does not fully describe the options & capabilities of
  15. the 80386+ processors as that would take volumes. It is instead meant 
  16. to be a simple FYI type overview for those that may be interested.:
  17.  
  18. Intel's "Code Builder Kit" creates 32 bit protected mode programs that take
  19. advantage of the enhanced memory management of the 80386+ processors. These
  20. processors have 3 main modes of operation generally known as the "real",
  21. "virtual 86" and "386 protected" modes.
  22.  
  23.  The "real" mode of operation is what most people are familiar with. In
  24. this mode the CPU "emulates" an 8086/8088 based machine. The 8086 is
  25. capable of addressing 1 meg of memory, to maintain compatibility this
  26. limit is also imposed on the '386/'486 processors when running in this
  27. mode. This is the mode that MS-DOS, and the overwhelming majority of IBM PC
  28. based applications, operate in. The area generally known as "conventional
  29. memory" is the first 640K of this memory block with the second 384K being
  30. used for the built in BIOS ROMS, I/O buffers (such as video) and things
  31. like EMS page frame addresses. That is all the memory the 8086/8088
  32. processors are capable of directly manipulating. Basically a 386/486 running
  33. in real mode is nothing more than a fast 8086 based machine. In actual
  34. operation the 386/486 CPU's *are* capable of using an additional 64K of
  35. memory beyond what the 8086 is capable of. This is what 386/486 memory
  36. managers are referring to at boot time with messages such as "64K high
  37. memory area available". All the memory in the machine must be dealt with in
  38. "chunks" (called segments) no larger than 64K in this mode.
  39.  
  40.  The "virtual 86" mode is what programs such as Windows run MS-DOS programs
  41. in. Basically the CPU sets up "virtual" machines that all run independently
  42. but retain the limits imposed by running in real mode. In this mode several
  43. programs can be run "at the same time" with all of them thinking they are
  44. running, by them selves, on an 8086 based machine. The advantage of this
  45. mode is that each of the virtual machines may be separated, to some extent,
  46. in hardware (thru the 386+ processors memory management) and is thus less 
  47. subject to problems between applications.
  48.  
  49.  The "386 protected mode" is quite different from both of these modes,
  50. bearing more similarity to CPU's like the Motorola 680x0 series used in the
  51. Macintosh. This is the mode that POV-Ray spends most of it's time running
  52. in. The mode offers the ability to load applications in separate areas of
  53. memory and logically remap that memory to any address in the machine.
  54. Memory available in this mode can be configured as a linear address space
  55. of 4 GigaBytes. (From 0 to 2^32-1 addresses, also called the "flat memory
  56. model".) This memory may be allocated and dealt with at any size, the DOS
  57. 64K segment is gone as is the DOS "640K limit". 4,294,967,294 bytes of RAM
  58. are theoretically available to POV-Ray in this mode, of course machine and
  59. compiler limitations dictate what is "really" available. Given a machine
  60. with sufficient resources POV-Ray can directly use 64 megabytes of physical
  61. RAM and (thru the Virtual Memory Manager) additional disk space to total
  62. 3.75 Gigabytes of virtual memory.  I.E. POV-Ray has the ability to use 3.75
  63. GIGABYTES of memory. Intels Code Builder (ICB) reserves the first megabyte
  64. of "real mode" memory in the machine for a "scratch pad" area and for
  65. communication with the machines built in BIOS and DOS since THEY are 16 bit
  66. "programs". "Freeing up conventional RAM" has no meaning in this context,
  67. POV-Ray does not use the area for much. The POVRAY.EXE file actually 
  68. contains 5 "programs". A Loader/DOS extender (used to add 32 bit
  69. functions to MS-DOS since MS-DOS is a 16 bit operating system), a Virtual
  70. Memory Manager, a protected mode 80387 emulator to provide floating point 
  71. math operations in a machine with no CoProcessor installed, and the POV-Ray
  72. program it's self. When POVRAY.EXE is invoked the "loader" is loaded by DOS
  73. & executed, it in turn loads the DOS extender which checks for the presence
  74. of a DPMI *HOST* memory manager. (Common DPMI hosts are Windows, OS/2 2.x in 
  75. a DOS VDM, and Quarterdecks QEMM with their QDPMI add on installed. 386MAX is
  76. also supposed to provide it but I have not verified it's operation. I
  77. have tried all the others & they work fine.)
  78.  
  79.  **** This is where it gets complicated <g> ****  IF an *existing* DPMI
  80. host/memory manager (say Windows) is found to be *already* running the DOS
  81. extender USES IT for ALL memory requests **AND** virtual memory management.
  82. I.E. Windows IT'S SELF provides POV-Ray with all it's memory management and
  83. the configuration of *WINDOWS* imposes the limits on what the program can
  84. use.  (How much extended memory is allocated to the application, the size
  85. that the Windows swap file is, and can go to.... etc.) If a DPMI host is found
  86. to be in operation POV-Ray (ICB) will "gut" it's own virtual memory manager
  87. (since it's not used in this case) to conserve RAM.
  88.  
  89.  If NO DPMI host is found then the DOS Extender in POV-Ray will provide the
  90. memory management for the program. (It is NOT, however, a DPMI host) The
  91. parameters the program will *expect* to be able to use are set with the
  92. POVMOD program. (Windows, OS/2 and QEMM/QDPMI *must* be configured to
  93. provide *at least* these parameters for POV-Ray to run. 
  94. It's *very important* that the program providing the DPMI host services be 
  95. configured to provide what POV-Ray *ASKS* for (which is in turn what is set 
  96. with POVMOD) or the program will error with an insufficient memory message.)
  97.  
  98.  The loader/extender then checks to see if a CoProcessor is installed in
  99. the machine. IF NONE IS FOUND the 80387 emulator is loaded. If a
  100. CoProcessor *is* detected the emulator is NOT loaded to conserve RAM. (Note
  101. that the emulator *will not work* correctly in a DOS VDM under OS/2 2.x, 
  102. the machine MUST have a CoProcessor installed for the program to function 
  103. well. Under Windows 3.x the VEMD.386 driver MUST be installed to run the 
  104. program on a machine with no CoProcessor. See the IBMPCEXE.DOC file for 
  105. more information.)
  106.  
  107.  At this point the actual execution of POV-Ray begins.
  108.  
  109. This is a (very) quick & basic overview of the programs operation and the 
  110. environment it executes in.
  111.  
  112. In answer to some specific questions:
  113.  
  114. > Does the "virtual memory manager" in POV run only if no existing hard
  115.   disk cache (like SMARTDRIVE) is detected?
  116.  
  117. No, the virtual memory manager is NOT a disk cache. It provides paged
  118. memory services to POV-Ray in much the same way that a Mainframe or
  119. MiniComputer may use their hard disk drives as "memory". This "memory" appears
  120. to the program to be actual RAM available for it's use. It is NOT a "swap
  121. file" in the conventional sense. (For this reason it's best that the file 
  122. used should be located on a drive that *DOES NOT USE DISK COMPRESSION 
  123. PROGRAMS* such as STACKER or SUPERSTOR!)  ICB allows this (plus physical 
  124. RAM) to go to a total of 3.75 Gigabytes.... if you have a big enough hard 
  125. drive.<g> 
  126. Disk caching will have little effect on the performance of POV-Ray.
  127. POV-Ray will "tolerate" it's being present, if new enough versions of the
  128. programs are used. (See IBMPCEXE.DOC) A MUCH better way to boost
  129. performance is to use the image buffering built into POV-Ray with the +bxxx
  130. commandline switch. Since POV-Ray must switch out of protected mode to use
  131. the BIOS disk service routines, it takes a performance hit for *every line*
  132. as it is written to disk. Also, since POV-Ray cares little about memory
  133. usage a buffer of 500K is not unreasonable in a machine with at least 4 Megs
  134. of RAM. I've done a couple timing tests and found that trace time can be
  135. reduced by as much as 30% with a 500K or larger buffer.
  136.  
  137. > What is the minimum amount of conventional DOS memory needed to run
  138.    POV? Does freeing up conventional memory above this minimum improve
  139.    performance?
  140.  
  141. No minimums are given in the ICB docs, I imagine all that is required is
  142. enough for the loader program to execute since it is (basically) a real mode
  143. program. Be aware however that machines with large amounts of memory taken
  144. up by drivers, TSR's etc. are MORE LIKELY to have some kind of problem with
  145. conflicts between POV-Ray and those drivers. (Simply because they *are*
  146. loaded and the vast differences in the way the CPU it's self is used
  147. between real mode and the 32bit protected mode.) Performance is not
  148. effected by how much real mode memory is available, POV-Ray runs almost
  149. completely in the area BEYOND the real mode 1meg boundary.
  150.  
  151. > I assume that if POV-Ray is a protected mode application, you should give
  152.    it as much *extended* memory as possible. How much can it use?
  153.  
  154. Yep, defiantly. The more the better since, as far as POV-Ray is concerned,
  155. this IS the memory. That is where the program actually runs. See
  156. IBMPCEXE.DOC for info on what switches to use with various memory managers
  157. to insure that extended memory is available for POV-Ray. As previously 
  158. described, POV-Ray (ICB's limits) can use 64 megabytes of physical RAM 
  159. (the IC's installed in the machine) and additional hard disk space to 
  160. total 3.75 Gigabytes of paged virtual memory.  
  161. NOTE however that "shortcuts" taken by some *hardware* manufacturers may 
  162. limit what is "really" available to the program, even if more is actually 
  163. installed in the machine. Generally you are pretty safe in assuming that 
  164. 16 megabytes of RAM and 32 megabytes of disk space will be usable/available 
  165. in *ANY* IBM compatible 386/486 PC with an ISA buss. 48 megabytes of VM 
  166. should be plenty for any rendering that will be completed in under a 
  167. century.... <g> Also note that I have gotten some messages (2 to be exact) 
  168. from people that have been unable to get the program to run in a machine 
  169. with only 2 megs of RAM installed. Since the first meg is "reserved" for 
  170. real mode use this leaves 1 meg for POV to knock around in. POV is actually 
  171. a pretty big program it's self these days, and getting bigger. 
  172. 4 megs gives it some "breathing space".
  173.  
  174.  
  175. > What options will allow the program to run as fast as it can?
  176.  
  177. Generally the command line options that have the most effect are the image
  178. buffering (+bxxx) and the keyboard abort (+x). The image buffering can 
  179. dramatically reduce rendering times. A setting of +b512 on a machine with
  180. 4+ megs of RAM is a good compromise between the buffer & how much RAM is
  181. "sacrificed" to the buffer. For instance a 512K buffer will limit an 800x600
  182. image to just 3 disk writes during the image generation instead of ** 600 **.
  183. Depending on the environment, the keyboard abort option (+x) can slow things
  184. quite a bit too. It's most noticeable in multitasking environments since
  185. the keyboard is constantly polled to check for the occurrence of any keypress. 
  186.  
  187. Disabling the display option can give a slight improvement in rendering
  188. speed, but it is generally not a very significant improvement.
  189.  
  190.  
  191. A note about benchmarking POV-Ray:
  192.  
  193. Unfortunatly for benchmarking purposes the images that run the fastest also
  194. tend to have the very widest variations from compiler to compiler. That
  195. results in essentially meaningless comparisons since it doesn't represent the
  196. average performance difference you will see in day to day use of the program.
  197. The ways that various compiler designers implement solutions to functions can
  198. cause -really- wide variations between EXE's, completely dependant on what
  199. image is being rendered. For instance BLOB.POV will render about 20% or so
  200. faster with a Watcom 9.5 compile than the ICB 1.0 compile of version 1.0, but
  201. something like ARCHES.POV is only about 7%-8% faster. A 12% variation between
  202. just 2 images. About a year ago I did a whole bunch of comparisons using a
  203. couple dozen images that used various features of the raytracer. SKYVASE.POV
  204. *generally* seems to result in about the same speed differences between
  205. compilers as what the average results of all those images turned out to be. If
  206. you turn on anti-aliasing things tend to tighten to closer render times too.
  207. Different methods of handling disk access can also skew things, you end up
  208. measuring the I/O efficiency of the compiler rather than the floating point
  209. math capability. You can use the -bxxx image buffering to eliminate, or
  210. at least significantly reduce, that.
  211.